feat: add service-scoped env to Foundry extensions - #9079

Seven threads from my earlier passes are still open on this HEAD with no replies. Listing them so they don't get lost now that the PR is showing approved.

• env_refs.go resolveVars divergence: I added detail on that thread. The :- half fails silently, and a value the user was prompted for ends up in the Bicep param as literal text.
• helpers.go the service env read swallows the RPC error and leaves hasServiceEnvironment false, so the run path falls back to the full azd environment, which is the leak this PR closes. Routines and toolboxes return the error instead.
• agent_definition.go ResolveAgentEnvironmentVariable falls through to the caller mapping for any name a declared env: doesn't carry, and both callers hand it the full azd environment.
• resource_services.go setServiceEnvironment returns before writing when collection comes back empty, so a service with no ${VAR} references gets no env: key and reads as legacy at run time.
• env_refs.go environmentReferenceAt never checks that the byte after $ is {. "$HOME}" reports OME while foundry.ExpandEnv leaves the value untouched, which is the exact invariant TestFindEnvironmentReferencesMatchesExpander asserts.
• env_refs_test.go every value in that parity corpus has $ followed by {, so it can't catch the case above.
• env_refs_test.go the TestNestedDefaultIsNotDiscovered comment says the outer name reaches init prompting, but the assertion four lines down is require.Empty.

None of these are new asks, they're the same threads. The two scanner ones and the two test ones are narrow. The three that fall back to the full azd environment are the ones I'd want settled before this merges, since they all undo the isolation the PR is adding.

Approving, pending addressing Jon's comments, and with a possible suggestion to consider now or as a follow up, if it would indeed make things easier.

Pull request overview

Copilot reviewed 44 out of 44 changed files in this pull request and generated 1 comment.

One gap left over from the empty-env change.

• init.go:2960 and init_from_code.go:873: agent init still goes through the guarded setServiceEnvironment, so an agent with no collected variables gets no env: key and falls back to the full azd environment at run time.

Pull request overview

Copilot reviewed 45 out of 45 changed files in this pull request and generated 5 comments.

One issue with the empty-env fix in fc54476.

HIGH

• setServiceEnvironmentScope sends env: {} over the config RPC, but core drops it before it reaches azure.yaml, so a generated agent service with no variables of its own still reads back as legacy and inherits the whole azd environment. Details inline on resource_services.go.

Both init call sites now route through the new function and the tests do pin that, so the gap isn't in this commit. It's one layer down, in how ServiceConfig.Environment is serialized.

Pull request overview

Copilot reviewed 44 out of 44 changed files in this pull request and generated no new comments.

Incremental change since my last review checks out. The unpersistable env: {} write is gone, both init paths and addResourceService route through setServiceEnvironment, and the comment records why an explicit empty env can't survive the save today. Build, vet, and the agents cmd suite pass locally against 88a6b76.

One optional follow-up: this behavior flipped twice in the PR, so a small test pinning that an empty environment writes no env: key would keep it from coming back by accident. resource_services_test.go is the natural home now that TestAddResourceServiceWritesEmptyEnvironment is gone.

Re-verified against 88a6b76: the shared ${VAR} scanner (escape collapsing so $${VAR} stays literal while $$${VAR} expands, balanced-default depth counting, and the probe-based check that keeps Foundry ${{...}} spans reserved), the Initialize reordering that resolves the azd environment before reading service environments, and the run-time precedence chain: process env, then service env, then the FOUNDRY_* platform values, then legacy definition env, with the Windows case-insensitive match preserved.

No blocking issues found.